Enregistrement du serveur de noms NamecheapLa configuration d'un serveur DNS pour être responsable des noms de domaine peut être une tâche complexe, même pour les administrateurs chevronnés. La gestion de la zone DNS est un devoir vital, mais peut être déconcertante, surtout lorsque vous essayez de démarrer.
Un logiciel comme le serveur DNS Bind est incroyablement flexible et peut être configuré pour fonctionner avec autant de composants dans la hiérarchie DNS globale. Cependant, cette flexibilité signifie également que Bind n'est pas optimisé pour une seule tâche. Cela a quelques effets secondaires.
La plupart du temps, il existe d'énormes blocs de fonctionnalités dont votre configuration n'a pas besoin. Cette complexité supplémentaire rend la gestion plus difficile. Cela signifie également que le logiciel lui-même sera moins réactif pour une tâche donnée.
Pour résoudre ce problème, des serveurs DNS alternatifs ont été créés qui se spécialisent dans un seul domaine de résolution DNS. Un logiciel appelé NSD est un serveur DNS faisant uniquement autorité qui est idéal pour gérer les zones DNS avec autorité. Sans avoir à se soucier de la récursivité ou de la mise en cache, ce serveur fonctionne avec des performances élevées et un encombrement réduit.
Dans ce guide, nous allons montrer comment installer et configurer NSD pour administrer en toute sécurité nos zones DNS sur les serveurs Ubuntu 14.04.
Avant de commencer ce guide, vous devez vous familiariser avec certains concepts et terminologies DNS de base . Si vous avez besoin d'aide pour comprendre à quoi sert un serveur DNS faisant uniquement autorité, consultez notre guide sur les différences entre les types de serveurs DNS .
En tant que serveur DNS faisant uniquement autorité, NSD ne fournit aucune fonctionnalité de mise en cache, de transfert ou récursive. Il ne répond qu'aux requêtes itératives des zones qu'il contrôle. Il peut également référer des résolveurs à d'autres serveurs de noms pour les zones qu'il a déléguées.
Aux fins de ce guide, nous allons configurer deux serveurs avec le logiciel NSD pour agir en tant que serveurs principaux et secondaires pour nos zones. Nous fournirons également des données de configuration qui permettront aux clients d'accéder à un serveur Web sur un troisième hôte.
Nous utiliserons le domaine factice example.compour ce guide. Vous devez remplacer votre propre domaine pour suivre. Les machines que nous allons configurer auront les propriétés suivantes:
Objectif | DNS FQDN | Adresse IP |
Serveur de noms principal | ns1.example.com. | 192.0.2.1 |
Serveur de noms secondaire | ns2.example.com. | 192.0.2.2 |
Serveur Web | 192.0.2.3 |
Une fois que vous aurez terminé ce guide, vous devriez avoir configuré les deux premiers serveurs avec NSD pour qu'ils fassent office de serveur faisant uniquement autorité pour vos zones. Vous pourrez utiliser les noms d'hôtes que nous configurons pour atteindre vos serveurs depuis Internet, ainsi que découvrir les noms d'hôtes en interrogeant les adresses IP. Tout client de résolution capable d'atteindre nos serveurs pourra obtenir les données de domaine de nos serveurs.
La première étape que nous devons franchir est une étape préparatoire. Avant de nous préoccuper de la configuration du DNS, nous devons nous assurer que nos serveurs de noms peuvent résoudre correctement leur propre nom d'hôte de la manière dont nous le souhaitons.
Sur votre premier serveur DNS, modifiez le fichier /etc/hosts pour configurer le FQDN de cet ordinateur :
sudo nano /etc/hosts
Dans notre cas, nous avons besoin de cartographier l' 192.0.2.1adresse IP pour le nom complet de notre premier serveur de noms, ns1.example.com. Nous pouvons le faire en remplaçant la ligne qui spécifie notre nom d'hôte par notre adresse IP publique, le FQDN et l'alias raccourci pour notre hôte:
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1
Enregistrez et fermez le fichier lorsque vous avez terminé.
Ensuite, nous devons revérifier le /etc/hostnamefichier:
sudo nano /etc/hostname
Cela devrait contenir la valeur de notre nom d'hôte non qualifié . Modifiez-le si nécessaire:
ns1
Enregistrez et fermez le fichier lorsque vous avez terminé.
Si vous avez modifié le /etc/hostnamefichier ci-dessus, dites au système de relire le fichier:
sudo hostname -F /etc/hostname
Nous en avons fini avec notre premier serveur DNS pour le moment. Répétez les étapes sur le deuxième serveur.
Modifiez le /etc/hostsfichier pour spécifier l'hôte du deuxième serveur DNS:
sudo nano /etc/hosts
127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2
Vérifiez également le /etc/hostnamefichier. Cela ne devrait avoir que le nom court non qualifié:
sudo nano /etc/hostname
ns2
Encore une fois, faites relire le fichier par le système si vous deviez modifier quoi que ce soit:
sudo hostname -F /etc/hostname
Vos serveurs peuvent désormais résoudre leurs propres noms sans utiliser DNS. Vous êtes maintenant prêt à configurer NSD sur vos serveurs.
L'étape suivante consiste à installer réellement le logiciel sur vos serveurs de noms.
Avant de commencer, nous devons en fait franchir une étape préparatoire supplémentaire. Le package NSD dans les dépôts installe le logiciel, configure certains composants et tente de démarrer le service. Le service s'attend à s'exécuter en tant qu'utilisateur appelé nsd, mais le package ne crée pas réellement ce compte d'utilisateur.
Pour éviter une erreur lors de l'installation, nous créerons cet utilisateur avant d' installer le logiciel. Sur chacune de vos machines, créez l' nsdutilisateur système en tapant:
sudo useradd -r nsd
Cela créera le compte correct nécessaire pour terminer l'installation avec succès.
Maintenant, nous avons juste besoin d'installer le logiciel NSD. Heureusement, NSD est inclus dans les référentiels Ubuntu 14.04, nous pouvons donc simplement l'utiliser aptpour le retirer. Nous mettrons à jour notre index de package local, puis téléchargerons le package approprié:
sudo apt-get update
sudo apt-get install nsd
Cela installera le logiciel et effectuera une configuration initiale. Il démarrera également le service, même si nous ne l'avons pas encore configuré pour servir quoi que ce soit.
Nous allons commencer par configurer notre ns1serveur, qui sera configuré comme serveur DNS principal pour nos zones.
La première chose que nous devons faire est de nous assurer que toutes les clés SSL et tous les certificats que NSD utilise pour communiquer en toute sécurité entre la partie démon de l'application et le contrôleur sont générés.
To do this, type:
sudo nsd-control-setup
There are probably already keys and certificates present in the /etc/nsd directory, but this command will generate anything that is missing.
Le fichier de configuration principal de NSD est un fichier appelé nsd.conf situé dans le répertoire /etc/nsd.
Ce répertoire contient déjà un fichier contenant seulement quelques commentaires, mais nous utiliserons un fichier d'exemple plus complet comme modèle. Copiez ce fichier maintenant pour écraser le fichier actuel :
sudo cp /usr/share/doc/nsd/examples/nsd.conf /etc/nsd/nsd.conf
Maintenant, ouvrez le nouveau fichier dans votre éditeur de texte avec les privilèges sudo :
sudo nano /etc/nsd/nsd.conf
À l'intérieur, vous verrez un certain nombre de lignes de configuration commentées, organisées en sections. Les principales sections sont le serveur, le contrôle à distance, la clé, le modèle et la zone. Nous utiliserons la plupart d'entre elles pour notre configuration.
Pour commencer, nous devrions configurer les propriétés de base de notre serveur DNS dans la section serveur. Nous traiterons le trafic IPv4 de base sur le port DNS 53 par défaut. Nous utiliserons l'utilisateur nsd que nous avons configuré précédemment. La plupart de ces valeurs seront les valeurs par défaut, mais nous décommenterons les lignes associées pour rendre leurs valeurs explicites.
Nous voulons également définir explicitement le répertoire qui contient nos données de zone, ainsi que l'emplacement de nos fichiers log et pid. Il existe de nombreux autres choix de configuration que vous pouvez définir pour cette section, mais nous allons rester relativement simples. N'hésitez pas à apporter des modifications supplémentaires.
Notre section serveur ressemblera à ceci :
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"
Ensuite, jetons un œil à la remote-controlsection. Cette section est un peu impropre car elle n'est pas seulement utilisée pour le contrôle à distance de notre démon. Nous allons configurer cela pour contrôler le démon localement.
Tout d'abord, nous devons activer la ressource et définir son interface et son numéro de port. Tout cela peut être fait en supprimant les commentaires des lignes appropriées et en changeant la control-enabledirective en «oui».
Ensuite, nous pouvons décommenter les lignes qui spécifient les fichiers de clés et de certificats. Ceux-ci correspondent aux noms de fichiers générés lorsque nous avons exécuté la nsd-control-setupcommande et ne devraient pas avoir besoin d'être modifiés une fois qu'ils ne sont pas commentés.
Nos valeurs pour cette section devraient ressembler à ceci:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"
Ensuite, nous allons configurer la keysection. Cette section contiendra les clés secrètes que NSD utilisera pour exécuter en toute sécurité les transferts de zone entre nos serveurs principal et secondaire.
Nous devons définir le nom et l'algorithme qui seront utilisés. Nous utiliserons le nom demokeypour notre exemple. Nous utiliserons également l'algorithme par défaut ( hmac-sha256) qu'ils ont sélectionné.
Pour le secret lui-même, nous prendrons les conseils dans le commentaire sur la façon d'en générer un en toute sécurité. Quittez l'éditeur de texte. Dans votre terminal, exécutez la commande suivante:
dd if=/dev/random of=/dev/stdout count=1 bs=32 | base64
Vous recevrez une clé générée aléatoirement dans la sortie de la commande:
0+1 records in
0+1 records out
19 bytes (19 B) copied, 0.000571766 s, 33.2 kB/s
+kO0Vu6gC+9bxzMy3TIZVLH+fg==
Copiez la sortie en rouge ci-dessus et ouvrez à nouveau votre fichier de configuration. Utilisez la sortie copiée comme valeur du secretparamètre. Cette section devrait ressembler à ceci:
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
Ensuite, nous établirons un schéma simple puisque nous avons des informations répétitives impliquant notre serveur secondaire. Nous notifierons et transférerons nos zones au même serveur secondaire à chaque fois, donc la création d'un modèle est logique.
Nous appellerons notre modèle tosecondaire pour décrire à quoi il servira. Nous définirons le nom et le fichier de chaque zone individuellement, de sorte que nous n'ayons pas à nous en préoccuper dans le modèle.
Nous voulons définir le paramètre de notification dans notre modèle pour qu'il fasse référence à l'adresse IP de notre serveur secondaire. Nous voulons également utiliser la clé que nous avons spécifiée pour transférer les zones en toute sécurité avec le TSIG. Nous configurerons le paramètre "Provide-xfr" exactement de la même manière.
En fin de compte, notre section de modèle devrait ressembler à ceci :
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokey
Enfin, nous arrivons à notre section de zone. Ici, nous configurons la manière dont NSD traitera nos zones spécifiques et les fichiers qui leur sont associés.
Tout d'abord, nous configurons notre zone de transmission. Nous devons configurer la zone pour notre zone example.com. Pour cela, il suffit de spécifier le domaine lui-même sous le paramètre "name", de préciser le nom que nous utiliserons pour le fichier de zone, et d'inclure le modèle que nous avons créé ci-dessus afin de le transférer sur notre serveur secondaire.
La zone forward terminée pour notre démo devrait ressembler à ceci :
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"
Ensuite, nous pouvons nous occuper de la zone de retour. Une zone inversée est en fait un fichier de zone qui permet au logiciel DNS de mapper une adresse IP avec un nom d'hôte pour les clients. En général, dans le cas d'un hébergement comme DigitalOcean, c'est le fournisseur d'hébergement qui s'en charge.
Par exemple, avec DigitalOcean, vous n'êtes pas délégué la responsabilité d'une série d'adresses IP pour établir des correspondances inversées. Au lieu de cela, DigitalOcean crée automatiquement les mappages inversés nécessaires si vous définissez le nom d'hôte du serveur dans le panneau de contrôle au FQDN auquel vous souhaitez qu'il soit mappé.
Vous pouvez en savoir plus sur les reverse mappings en lisant la section "A Bit About Reverse Zones" du guide Bind qui fait autorité uniquement. Nous vous montrerons comment configurer les zones inversées pour le FQDN à des fins d'information et pour une plus grande flexibilité, même si cela ne sera pertinent que dans les situations où vous avez été délégué le contrôle des cartographies inversées pour un bloc d'IP.
Pour une zone inversée, nous prenons les trois premiers octets de l'adresse IP, les inversons et les ajoutons en tant que délégations de sous-domaines au domaine spécial in-addr.arpa. C'est ainsi que le système DNS recherche les adresses IP en utilisant les mêmes méthodes de recherche que pour les domaines ordinaires. Dans notre cas, nous allons créer une zone inversée qui définit le mappage 2.0.192.in-addr.arpa. Elle sera très similaire à la spécification de la zone avant :
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"
Enregistrez et fermez le fichier lorsque vous avez terminé.
Maintenant, nous devons créer le fichier de zone avancée. Dans notre configuration, nous avons nommé le fichier de zone "exemple.com.zone". Nous devrons créer un fichier avec ce nom dans notre répertoire /etc/nsd.
Ouvrez ce fichier dans votre éditeur de texte avec les privilèges sudo :
sudo nano /etc/nsd/example.com.zone
La première chose que nous devons faire est de définir quelques paramètres au sommet. Nous allons définir le paramètre $ORIGIN qui pointe vers le domaine que nous configurons au format FQDN (avec le point final). Nous voulons également définir la durée de vie par défaut. Nous utiliserons 1800 secondes, ou 30 minutes :
$ORIGIN example.com.
$TTL 1800
Ensuite, nous avons besoin de notre SOA, ou début d'enregistrement d'autorité. Cela ressemblera à ceci :
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
Cela définit certaines valeurs à l'échelle de la zone. La valeur ns1.example.com. est utilisée pour spécifier l'emplacement du domaine d'un des serveurs faisant autorité pour cette zone. La valeur admin.example.com. est utilisée pour spécifier une adresse électronique où les administrateurs de la zone peuvent être joints.
L'adresse électronique, dans ce cas est admin@example.com. Dans un fichier de zone DNS, le symbole "@" doit être transformé en point. Le point de terminaison est également important, comme c'est toujours le cas lorsqu'on spécifie un FQDN.
Les valeurs entre parenthèses définissent certaines des valeurs de notre zone. La seule que nous mentionnerons ici est le numéro de série. Cette valeur doit être incrémentée chaque fois que vous apportez une modification au fichier de zone. Ici, nous faisons une démonstration en utilisant la date de cette écriture (02 juillet 2014) plus un numéro de révision.
Ensuite, nous devons utiliser les enregistrements NS pour définir les serveurs de noms qui font autorité pour cette zone. N'oubliez pas d'utiliser le FQDN pour votre domaine, y compris le point de terminaison :
IN NS ns1.example.com.
IN NS ns2.example.com.
Ensuite, nous devons mettre en place les enregistrements A qui indiqueront effectivement aux clients comment atteindre les serveurs de noms que nous avons spécifiés. C'est ce qui fait correspondre nos noms d'hôtes à leurs adresses IP réelles :
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
Enfin, nous voulons ajouter des enregistrements A supplémentaires pour nos autres hôtes. Dans notre cas, nous allons configurer notre domaine de base ( example.com) et le wwwnom d'hôte à mapper à notre serveur Web:
@ IN A 192.0.2.3
www IN A 192.0.2.3
Lorsque vous avez terminé, votre fichier terminé devrait ressembler à ceci:
$ORIGIN example.com.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
; Additional A records
@ IN A 192.0.2.3
www IN A 192.0.2.3
Enregistrez et fermez le fichier lorsque vous avez terminé.
Ensuite, nous allons créer un fichier similaire pour notre zone inverse. N'oubliez pas que cela n'est nécessaire que si vous avez été délégué la responsabilité du mappage inverse d'un bloc d'adresses.
Créez le fichier de zone inverse que vous avez référencé dans votre nsd.conffichier et ouvrez-le avec les privilèges sudo dans votre éditeur de texte:
sudo nano /etc/nsd/192.0.2.zone
Encore une fois, nous commencerons par définir les paramètres $ORIGINet $TTL. Cette fois, n'oubliez pas de définir l'origine sur le in-addr.arpasous - domaine de votre zone. Dans notre cas, cela ressemblera à ceci:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
Ensuite, nous devons définir les enregistrements SOA, comme auparavant. Nous pouvons pratiquement utiliser les mêmes valeurs exactes pour ce fichier car le même e-mail et le même serveur de noms faisant autorité sont responsables des deux zones. De plus, les valeurs numériques devraient également fonctionner dans ce cas. N'oubliez pas de modifier le numéro de série à chaque fois que vous effectuez un changement:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
Lorsque vous avez terminé, le fichier devrait ressembler à ceci:
Encore une fois, nous devons définir les serveurs de noms faisant autorité pour la zone. Ce seront à nouveau les mêmes serveurs:
IN NS ns1.example.com.
IN NS ns2.example.com.
Enfin, nous devons fournir les mappages de domaines inversés réels en acheminant le dernier octet de chaque adresse IP vers le FQDN de l'hôte associé à l'aide d'enregistrements PTR :
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.
Lorsque vous avez terminé, le dossier doit ressembler à ceci :
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.
Enregistrez et fermez le fichier lorsque vous avez terminé.
Maintenant que notre serveur principal est configuré, nous pouvons tester notre fichier de configuration et mettre en œuvre nos changements.
Vous pouvez vérifier la syntaxe du fichier de configuration principal en utilisant l'outil nsd-checkconf inclus. Il vous suffit de pointer l'outil vers votre fichier de configuration principal :
sudo nsd-checkconf /etc/nsd/nsd.conf
Si le résultat est immédiat et sans sortie, cela signifie que la syntaxe de votre fichier de configuration principal est valide. Si vous obtenez une erreur, vérifiez la syntaxe de votre fichier de configuration pour corriger les erreurs éventuelles.
Une fois que vous êtes en mesure d'exécuter la vérification proprement, vous pouvez redémarrer le service en tapant :
sudo service nsd restart
Cela permettra d'arrêter et de démarrer le démon NSD.
Vérifiez les journaux pour voir les messages :
sudo tail -f /var/log/nsd.log
Vous devriez voir un certain nombre d'erreurs qui ressemblent à ceci :
. . .
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: received notify response error NAME ERROR from 192.0.2.2
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: max notify send count reached, 192.0.2.2 unreachable
This is here because NSD is attempting to transfer the zone to the secondary server, which has not been configured yet.
Maintenant que le serveur primaire est configuré, nous pouvons préparer le serveur secondaire.
Là encore, nous voulons nous assurer que nos certificats et nos clés SSL sont tous générés et disponibles. Pour ce faire, lancez la commande suivante :
sudo nsd-control-setup
Cela nous permettra de disposer de tous les fichiers d'identification nécessaires pour contrôler le démon.
Le fichier nsd.conf pour le serveur secondaire sera en grande partie le même que celui du serveur primaire. Il y a seulement quelques éléments que nous devrons modifier. Commencez par copier le fichier /etc/nsd/nsd.conf du serveur primaire dans le fichier /etc/nsd/nsd.conf du serveur secondaire.
Le fichier de ce serveur secondaire devrait maintenant ressembler à ceci :
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokey
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"
C'est presque exactement ce dont nous avons besoin.
Le serveur, la télécommande et les sections clés sont déjà entièrement configurés. Le "secret" de la section clé doit correspondre à la valeur du serveur principal, donc la copie du contenu complet du fichier permet de satisfaire facilement à cette exigence.
La première chose que nous devrons modifier est la section "pattern". La section que nous avons copiée est spécifique au serveur primaire, nous voulons donc la modifier pour aborder les choses du point de vue du serveur secondaire.
Tout d'abord, changez le nom en quelque chose de plus descriptif. Nous utiliserons la même convention et l'appellerons fromprimary. Nous devons également modifier les directives que cela définit. Au lieu du notifyparamètre, les serveurs secondaires ont besoin d'un allow-notifyparamètre, qui spécifie les serveurs autorisés à le notifier. Nous utiliserons toujours la même clé, il nous suffit donc de modifier le nom et l'adresse IP appropriée.
De la même manière, nous devons changer le provide-xfrparamètre en request-xfr. Le format de ceci change légèrement. Nous devons spécifier que nous voulons un transfert AXFR (le seul type dont les primaires NSD sont capables) et nous devons spécifier l'adresse IP et le numéro de port du primaire.
La patternsection ressemblera à ceci lorsque vous aurez terminé:
pattern:
name: "fromprimary"
allow-notify: 192.0.2.1 demokey
request-xfr: AXFR 192.0.2.1@53 demokey
Pour les zonesections, la seule chose que nous devons modifier est de include-patternfaire correspondre notre nouveau modèle que nous venons de créer:
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "fromprimary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "fromprimary"
Lorsque vous avez terminé, enregistrez et fermez le fichier.
Étant donné que notre serveur secondaire recevra toutes ses données de zone par le biais de transferts depuis le serveur principal, nous n'avons pas réellement besoin de configurer les fichiers de zone sur cet hôte.
Encore une fois, nous devons vérifier la syntaxe de notre fichier de configuration principal en tapant:
sudo nsd-checkconf /etc/nsd/nsd.conf
Si vous recevez des erreurs, vous devez revoir votre nsd.conffichier pour résoudre les problèmes de syntaxe. Si la commande retourne sans sortie, cela signifie que votre syntaxe est valide dans le fichier.
Lorsque votre fichier de configuration réussit le test, vous pouvez redémarrer le service en tapant:
sudo service nsd restart
Vérifiez les journaux pour vous assurer que tout se passe bien:
sudo tail -f /var/log/nsd.log
Désormais, vos serveurs NSD faisant uniquement autorité doivent être configurés et prêts à diffuser des informations DNS sur votre domaine. Nous devons encore configurer votre domaine afin qu'il sache utiliser vos serveurs de noms.
Pour ce faire, vous devez ajuster certains paramètres sous le bureau d'enregistrement où vous avez acheté votre nom de domaine. Une partie de la terminologie et certainement de l'interface variera d'un registraire à l'autre, mais vous devriez pouvoir trouver les paramètres si vous regardez attentivement.
Je vais montrer comment faire cela avec Namecheap , un registraire de noms de domaine assez standard.
Nous devons ajuster vos serveurs de noms d'une manière qui nous permettra de définir des enregistrements de colle sur le parent du domaine. Cela est nécessaire lorsque les serveurs de noms se trouvent dans le domaine lui-même.
Lorsque vous déléguez un sous-domaine (comme à example.compartir du comdomaine), vous devez spécifier les serveurs de noms faisant autorité pour le domaine. Si les serveurs de noms se trouvent dans le domaine, vous devez également inclure un enregistrement de collage, qui est simplement un enregistrement A pour chacun des serveurs de noms faisant autorité pour la zone déléguée.
Nous en avons besoin parce que les recherches DNS seraient prises dans une boucle si les enregistrements de colle n'étaient pas inclus. Les clients demanderaient à notre bureau d'enregistrement qui fait autorité pour le domaine example.comet notre bureau d'enregistrement (après avoir configuré cela) retournerait ns1.example.comet ns2.example.com. Si nous n'incluons pas les enregistrements A pour les résoudre en adresses IP, le client ne pourra jamais dépasser ce point. Il n'aurait aucun moyen de trouver les adresses IP des serveurs de noms dont il a besoin car elles sont généralement définies dans les serveurs de noms eux-mêmes.
L'emplacement dans l'interface du registraire où vous pouvez configurer vos serveurs de noms et leurs adresses IP associées variera en fonction de votre fournisseur. Avec Namecheap, il existe une section intitulée «Enregistrement du serveur de noms» qui vous permet de définir les adresses IP des serveurs de noms pour créer des enregistrements de colle:
Enregistrement du serveur de noms NamecheapIci, vous pouvez configurer les serveurs de noms et les mapper à une adresse IP spécifique:
Serveurs de noms de carte NamecheapLorsque vous aurez terminé, vous devrez définir les serveurs de noms actifs utilisés pour votre domaine. Namecheap a une option appelée «Configuration du serveur de noms de domaine» qui accomplit cela:
Namecheap set serveurs de nomsDans l'interface que vous obtenez en sélectionnant cette option, vous pouvez entrer les noms d'hôte de vos serveurs de noms que vous venez d'enregistrer:
Serveurs de noms d'entrée NamecheapLes modifications que vous apportez à votre bureau d'enregistrement peuvent prendre un certain temps à se propager. Les données mettront également plus de temps à se propager au reste des serveurs DNS du monde. En règle générale, ce processus devrait se terminer dans les prochaines 24 à 48 heures.
À l'aide de ce guide, vous devez maintenant disposer de serveurs DNS principaux et secondaires faisant uniquement autorité qui peuvent être utilisés pour diffuser des informations DNS sur vos domaines. Contrairement à Bind, NSD est optimisé pour un comportement faisant autorité à haute performance, afin que vous puissiez obtenir de meilleures performances qui sont adaptées spécifiquement à vos besoins.